home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
gnu
/
gprof
/
gpfbin07.zoo
/
gprof.txt
< prev
next >
Wrap
Text File
|
1991-06-27
|
37KB
|
867 lines
Info file: gprof, -*-Text-*-
produced by texinfo-format-buffer
from file: gprof.texinfo
This file documents the gprof profiler of the GNU system.
Copyright (C) 1988 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions.
File: gprof Node: Top, Prev: Top, Up: (dir), Next: Why
Profiling a Program: Where Does It Spend Its Time?
**************************************************
This manual describes the GNU profiler `gprof', and how you can use it
to determine which parts of a program are taking most of the execution
time. We assume that you know how to write, compile, and execute programs.
GNU `gprof' was written by Jay Fenlason.
* Menu:
* Why:: What profiling means, and why it is useful.
* Compiling:: How to compile your program for profiling.
* Executing:: How to execute your program to generate the
profile data file `gmon.out'.
* Analyzing:: How to run `gprof', and how to specify
options for it.
* Flat Profile:: The flat profile shows how much time was spent
executing directly in each function.
* Call Graph:: The call graph shows which functions called which
others, and how much time each function used
when its subroutine calls are included.
* Implementation:: How the profile data is recorded and written.
* Sampling Error:: Statistical margins of error.
How to accumulate data from several runs
to make it more accurate.
* Assumptions:: Some of `gprof''s measurements are based
on assumptions about your program
that could be very wrong.
* Incompatibilities:: (between GNU `gprof' and Unix `gprof'.)
File: gprof Node: Why, Prev: Top, Up: Top, Next: Compiling
Why Profile
***********
Profiling allows you to learn where your program spent its time and which
functions called which other functions while it was executing. This
information can show you which pieces of your program are slower than you
expected, and might be candidates for rewriting to make your program
execute faster. It can also tell you which functions are being called more
or less often than you expected. This may help you spot bugs that had
otherwise been unnoticed.
Since the profiler uses information collected during the actual execution
of your program, it can be used on programs that are too large or too
complex to analyze by reading the source. However, how your program is run
will affect the information that shows up in the profile data. If you
don't use some feature of your program while it is being profiled, no
profile information will be generated for that feature.
Profiling has several steps:
* You must compile and link your program with profiling enabled.
*Note Compiling::.
* You must execute your program to generate a profile data file.
*Note Executing::.
* You must run `gprof' to analyze the profile data.
*Note Analyzing::.
The next three chapters explain these steps in greater detail.
The result of the analysis is a file containing two tables, the
"flat profile" and the "call graph" (plus blurbs which briefly
explain the contents of these tables).
The flat profile shows how much time your program spent in each function,
and how many times that function was called. If you simply want to know
which functions burn most of the cycles, it is stated concisely here.
*Note Flat Profile::.
The call graph shows, for each function, which functions called it, which
other functions it called, and how many times. There is also an estimate
of how much time was spent in the subroutines of each function. This can
suggest places where you might try to eliminate function calls that use a
lot of time. *Note Call Graph::.
File: gprof Node: Compiling, Prev: Why, Up: Top, Next: Executing
Compiling a Program for Profiling
*********************************
The first step in generating profile information for your program is
to compile and link it with profiling enabled.
To compile a source file for profiling, specify the `-pg' option when
you run the compiler. (This is in addition to the options you normally
use.)
To link the program for profiling, if you use a compiler such as `cc'
to do the linking, simply specify `-pg' in addition to your usual
options. The same option, `-pg', alters either compilation or linking
to do what is necessary for profiling. Here are examples:
cc -c myprog.c utils.c -pg
cc -o myprog myprog.o utils.o -pg
The `-pg' option also works with a command that both compiles and links:
cc -o myprog myprog.c utils.c -pg
If you run the linker `ld' directly instead of through a compiler such
as `cc', you must specify the profiling startup file
`/lib/gcrt0.o' as the first input file instead of the usual startup
file `/lib/crt0.o'. In addition, you would probably want to specify
the profiling C library, `/usr/lib/libc_p.a', by writing `-lc_p'
instead of the usual `-lc'. This is not absolutely necessary, but doing
this gives you number-of-calls information for standard library functions such
as `read' and `open'. For example:
ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p
If you compile only some of the modules of the program with `-pg', you
can still profile the program, but you won't get complete information about
the modules that were compiled without `-pg'. The only information
you get for the functions in those modules is the total time spent in them;
there is no record of how many times they were called, or from where. This
will not affect the flat profile (except that the `calls' field for
the functions will be blank), but will greatly reduce the usefulness of the
call graph.
So far GNU `gprof' has been tested only with C programs, but it ought
to work with any language in which programs are compiled and linked to form
executable files. If it does not, please let us know.
File: gprof Node: Executing, Prev: Compiling, Up: Top, Next: Analyzing
Executing the Program to Generate Profile Data
**********************************************
Once the program is compiled for profiling, you must run it in order to
generate the information that `gprof' needs. Simply run the program
as usual, using the normal arguments, file names, etc. The program should
run normally, producing the same output as usual. It will, however, run
somewhat slower than normal because of the time spent collecting and the
writing the profile data.
The way you run the program---the arguments and input that you give
it---may have a dramatic effect on what the profile information shows. The
profile data will describe the parts of the program that were activated for
the particular input you use. For example, if the first command you give
to your program is to quit, the profile data will show the time used in
initialization and in cleanup, but not much else.
You program will write the profile data into a file called `gmon.out'
just before exiting. If there is already a file called `gmon.out',
its contents are overwritten. There is currently no way to tell the
program to write the profile data under a different name, but you can rename
the file afterward if you are concerned that it may be overwritten.
In order to write the `gmon.out' file properly, your program must exit
normally: by returning from `main' or by calling `exit'. Calling
the low-level function `_exit' does not write the profile data, and
neither does abnormal termination due to an unhandled signal.
The `gmon.out' file is written in the program's *current working
directory* at the time it exits. This means that if your program calls
`chdir', the `gmon.out' file will be left in the last directory
your program `chdir''d to. If you d